Cisco has released Vulnerability-related.PatchVulnerability a new patch designed to fix Vulnerability-related.PatchVulnerability a failed update which has not prevented the exploit of a severe Webex vulnerability . The original security flaw , CVE-2018-15442 , is present in Vulnerability-related.DiscoverVulnerability the Cisco Webex Meetings Desktop App for Windows and is described Vulnerability-related.DiscoverVulnerability as a bug which `` could allow an authenticated , local attacker to execute arbitrary commands as a privileged user . '' Cisco 's original security update was published Vulnerability-related.PatchVulnerability in October in order to remedy Vulnerability-related.PatchVulnerability the flaw , in which a lack of validation for user-supplied parameters in the app could be harnessed to exploit the bug . If an attacker is successful in utilizing the vulnerability , they can force the app to run arbitrary commands with user privileges . `` While the CVSS Attack Vector metric denotes the requirement for an attacker to have local access , administrators should be aware that in Active Directory deployments , the vulnerability could be exploited Vulnerability-related.DiscoverVulnerability remotely by leveraging the operating system remote management tools , '' the company added . Software releases prior to 33.6.4 -- alongside Cisco Webex Productivity Tools Releases 32.6.0 and later prior to 33.0.6 -- are impacted on Windows systems . It was not long after the release Vulnerability-related.PatchVulnerability of the first patch that researchers from SecureAuth deemed the original fix incomplete . The original patch only forced the service to run files signed by Webex , but failed to account for DLL-based attacks , according to the team . `` The vulnerability can be exploited Vulnerability-related.DiscoverVulnerability by copying to a local attacker controller folder , the ptUpdate.exe binary , '' the researchers said Vulnerability-related.DiscoverVulnerability in an advisory . `` Also , a malicious dll must be placed in the same folder , named wbxtrace.dll . To gain privileges , the attacker must start the service with the command line : sc start webexservice install software-update 1 `` attacker-controlled-path '' ( if the parameter 1 does n't work , then 2 should be used ) . '' These findings were sent to Cisco , which acknowledged the DLL attack method . A new patch was then issued Vulnerability-related.PatchVulnerability roughly a week after being informed Vulnerability-related.DiscoverVulnerability of the issue . `` After an additional attack method was reported to Cisco , the previous fix for this vulnerability was determined to be insufficient , '' Cisco says . `` A new fix was developed Vulnerability-related.PatchVulnerability , and the advisory was updated Vulnerability-related.PatchVulnerability on November 27 , 2018 , to reflect which software releases Vulnerability-related.PatchVulnerability include the complete fix . ''

In November 8 , 2016 Microsoft released Vulnerability-related.PatchVulnerability a security update for Windows Authentication Methods ( MS16-137 ) which included 3 CVEs : Talking specifically about CVE-2016-7237 , this fix was applied Vulnerability-related.PatchVulnerability to `` lsasrv.dll '' , which affected the LSASS service . The vulnerability affected Vulnerability-related.DiscoverVulnerability all Windows versions , either 32 or 64 bits , and was reported Vulnerability-related.DiscoverVulnerability and later described Vulnerability-related.DiscoverVulnerability in more detail by Laurent Gaffié ( @ PythonResponder ) the same day that the fix was published Vulnerability-related.PatchVulnerability . He also published proof-of-concept ( PoC ) code triggering the vulnerability . When the LSASS service crashes , the target is automatically restarted after 60 seconds , which is not very nice when it 's a production server . As this allocation is close to 4GB , this will probably fail.If the allocation fails , one of the necessary conditions to reproduce the NULL-Pointer dereference will be reached . There was a misunderstanding here about the vulnerability , because according to the PoC released by Laurent Gaffié , the problem WAS N'T in the structure pointer , but rather in one field of the CRITICAL_SECTION object pointed by this structure , which is NULL when the huge allocation fails ! To be clear , the check of the NULL pointer should probably have been here : Although the public PoC does n't trigger the vulnerability in Windows 8.1 or Windows 10 , the researcher and Microsoft declared these Windows versions as vulnerable . As I said before , the `` NegGetExpectedBufferLength '' function reads the evil size from the SMB packet . Now , this function has to return the 0x90312 value ( SEC_I_CONTINUE_NEEDED ) to produce the fail in the huge allocation . Unfortunately , in the latest Windows versions , an extra check was added in this function which compares the evil size against 0xffff ( 64KB ) . If the evil size is greater , this function wo n't return the 0x90312 value , but rather this will return the 0xC00000BB value ( STATUS_NOT_SUPPORTED ) , which wo n't produce any allocation fail resulting in the vulnerability not being triggered . On the other hand , if we use the evil size with a value less or equal than 0xffff ( 64KB ) , the allocation wo n't fail and again , the vulnerability wo n't be triggered . So , why are Windows 8.1 and Windows 10 vulnerable ? Although the bug is triggered when a memory allocation fails , that does n't mean that the allocation has to be giant , but rather that the LSASS service does n't have enough available memory to allocate . I had been able to confirm Vulnerability-related.DiscoverVulnerability that this vulnerability can be triggered in Windows 7 and 2008 R2 by establishing several SMB connections and sending evil sizes with values like 0x1000000 ( 16 MB ) . The problem is that in the case of the latest Windows versions , it 's not possible to use this kind of sizes , because as I said before , the limit is 64KB . So , the only way to trigger this vulnerability should be by producing a memory exhaustion in the LSASS service . It may be possible to do so by finding a controllable malloc in the LSASS authentication process , creating multiple connections and producing a memory exhaustion until the `` LsapAllocateLsaHeap '' function fails . Maybe , this memory exhaustion condition could be easily reached in local scenarios . I realized that the fix was n't working when I tried to understand why the public PoC was n't working against Windows 10 . It 's surprising to see that nobody else noticed that –that we know of- , and that a considerable amount of Windows users have been unprotected for more than 2 months since the public exploit was released . As of January 10th , Microsoft decided to release Vulnerability-related.PatchVulnerability a new security bulletin including a patch for the affected systems ( MS17-004 ) . If we diff against the latest `` lsasrv.dll '' version ( v6.1.7601.23642 ) , we can see that the vulnerability was fixed Vulnerability-related.PatchVulnerability by changing the '' NegGetExpectedBufferLength '' function . Basically , the same 64KB packet size check used by Windows 8.1 and Windows 10 was now added to the rest of the Windows versions